In the past, database management systems were designed for optimizing performance on hardware with limited amounts of main memory and with the slow disk access, both of which served as bottlenecks. The focus was thus on optimizing disk access, for example, by minimizing the number of disk pages to be read in to main memory, when processing a query.
Today, computer architectures have, however, changed. Using multi-core central processing units (“CPUs”), parallel processing may be possible with fast communication between processor cores (via main memory or shared cache). Main memory is no longer a limited resource. Modern computer architectures create new possibilities but also new challenges. With most, if not all, relevant data stored in memory, disk access is no longer a limiting factor for performance. With the increasing number of processing cores, CPUs will be able to process more and more data per unit interval of time.
Conventional database transactions occur between a transactional engine and a database, in which the transactional engine queries the database to create, retrieve, update, delete, insert, and the like data (e.g., a record) at the database. However, problems may occur when database transactions become distributed, i.e., when two transactional engines are used or when the transaction runs on more than one physical instance. These problems may include difficulty in identifying committed and uncommitted transactions, which are in progress. For example, even though two transactions are executed in parallel, a later, second transaction may need to know which of the records have been committed in an earlier transaction to ensure that the correct data is being used.